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ABSTRACT 


Multiple hosts wish to receive the same data from one or more senders. 
Multicast routing defines extensions to IP routers to support broadcasting data 
in IP networks. Multicast data is sent and received at a multicast address 
which defines a group. Data is sent and received in multicast groups via 
routing trees from sender(s) to receivers. Demonstrative lectures require to 
share the computer screen of the lecturer to the students as well as to make 
discussion with the students. The Multicast protocol is the most suitable 
method because of its capability in speed and better synchronized process. 
The word "multicast" is typically used to refer to IP multicast which is often 
employed for streaming media, and Internet television applications. 

KEYWORDS: Reliable multicast transport protocol, multicast classroom, IP 
routing, multicast lecturing 

INTRODUCTION 

Multicast conferencing is a rapidly-growing area of Internet use. Nowadays, 
most presentations in meetings, conferences and workshop seminars are using 
Power Point presentation software magnified by LCD projectors for efficiency 
and attraction. Similarly, demonstrative lectures require the same capability in 
the classroom. When demonstrating lecture (like running a program), the 
classroom require more than just presentation. This kind of application is 
known as "shared whiteboard". The screen of the lecturer's computer, is 
distributed to the classroom PCs. By using multicast algorithms, it minimizes 
the amount of traffic sent over the network. 
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Active services running in the network mediate between the 
clients (the student) and server (the lecturer). This paper 
provides an overview of the mechanisms used to support 
classroom shared whiteboard data transfer with multicast 
message conferencing capability. This system is used to 
advertise and invite individuals to the lectures, and then 
communicate among the students and the lecturer. 

Related works 

SLIM [3, 2] is a network layer single source multicast. As 
such it is most strongly related other single source multicast 
protocols, particularly [5] and [4]. The single source network 
layer multicast is the adequate and appropriate elementary 
multicast service and sufficient for more elaborate group 
communication sessions to be built upon. In fact, a multi¬ 
sender session can easily be created using our [3] or [5, 4]; 
SLIM leaves such issues to session management and out of 
the network layer protocol. 

Several multicast transport protocols were proposed to meet 
the requirements of delay-sensitive, real-time interactive 
applications, such as RTP/RTCP [12] to support multi-party 
multimedia conferencing tools, SRM [1] and TRM [10] to 
support distributed whiteboard tools, etc. These applications 
can tolerate a certain degree of data loss, but they are 
sensitive to packet delay variance. On the other hand, other 
protocols were proposed to meet the requirements of 
reliable data distribution services, such as multipoint file 
transfer. These applications are not delay-sensitive, but 
require that the information is entirely received, or else the 


transfer fails. The Muse protocol [6] (which was developed 
to multicast news articles on the MBone), MDP [8] (the 
evolution of a protocol used in disseminating satellite images 
over MBone) and MFTP [9], RMTP [7] and TMTP [12] (other 
protocols for reliable one-to-many data transmission) are 
examples of this kind of protocols. Most of them are designed 
to work in the MBone when the number of receivers is too 
large (thousands of receivers). To reach scalability and, 
therefore, to solve the feedback implosion problem, some of 
them define complex hierarchical topologies and they even 
introduce some non-layer 3 functionality into the network 
devices. 

A. Background theory 

Multicast messaging architecture Multicast means that the 
servers are automatically creating a tree-structure. A 
number of emerging network applications require the 
delivery of packets from one or more senders to a group of 
receivers. These applications include streaming continuous 
media (for example, the transfer of the audio, video, and text 
of a live lecture to a set of distributed lecture participants), 
shared data applications (for example, a whiteboard or 
teleconferencing application hat is shared among many 
distributed participants). For each of these applications, 
multicast is an extremely useful. The sending of a packet 
from one sender to multiple receivers with a single send 
operation. Multicast protocols allow a group or channel to be 
accessed over different networks by multiple stations 
(clients) for the receipt and transmit of multicast data. The 
main objective of multicast protocols for transporting real- 


@ IJTSRD | Unique Paper ID - IJTSRD27976 | Volume - 3 | Issue - 5 | July - August 2019 


Page 2533 








International Journal of Trend in Scientific Research and Development (IJTSRD] @ www.ijtsrd.com elSSN: 2456-6470 


time data is to guarantee quality of service by bounding end- 
to-end delay at the cost of reliability. Multicasting can 
dramatically reduce the network bandwidth multimedia 
applications require. Servers do not require hardware 
upgrades in order to take advantage of multicasting. Clients 
do not require hardware upgrades in order to take 
advantage of multicasting. Because routers of recent vintage 
already support multicasting, enabling multicasting on the 
network is practical and cost-effective. 

Types of reliable multicast protocols 

1. Scalable Reliable Multicast (SRM] 

2. Multicast Transport Protocol (MTP] 

3. Reliable Multicast Transport Protocol (RMTP] 

4. Reliable Multicast Distribution Protocol (RMDP] 

5. Pretty Good Multicast (PGM] 

RMTP (Global cast Communication] Reliable Multicast 
Transport Protocol (RMTP] organizes all the nodes into a 
tree structure. The receiving nodes are always at the bottom 
of the tree. Ideally the senders are at the top. The sender 
transmits messages using IP multicast, after a message is 
transmitted the sender will not release the memory until it 
receives a positive acknowledgement from the group. The 
receivers do not send acknowledgement directly to the top 
node (sender], but send hierarchical acknowledgements 
(HACKs]. A receiver transmits a HACK to their parent in the 
tree structure. The parent gathers all HACKs from its 
children and sends a HACK to its parent node one step 
higher in the tree. The HACKS are propagated upward to the 
top of the tree and the sender is eventually notified. This 
design allows dissemination of messages to a large number 
of receivers without causing ACK implosion. RLC and RMDP 
in Reliable Multicast Data Distribution Protocol (RMDP], the 
problem of insuring reliable data delivery to large groups, 
and adaptability to heterogeneous clients is solved by 
Forward Error Correction (FEC] technique based on erasure 
codes [11]. The basic principle behind the use of erasure 
codes is that the original source data, in the form of a 
sequence of k packets, along with additional n redundant 
packets, are transmitted by the sender, and the redundant 
data can be used to recover lost source data at the receivers. 
A receiver can reconstruct the original source data once it 
receives a sufficient number of (k out of n] packets. The main 
benefit of this approach is that different receivers can 
recover from different lost packets using the same 
redundant data. In principle, this idea can greatly reduce the 
number of retransmissions, as a single retransmission of 
redundant data can potentially benefit many receivers 
simultaneously. 

B. Applying multicast protocol 

Messaging structure of multicast classroom 
The network layout of the classroom as shown in Figures 1 
and 2, all the classroom PCs are connected through a 
network switch. For extensive usage that is if there are more 
than one classroom, PCs in each class are connected to a 
network switch, and all the switches of the classrooms are 
connected to a router. 

The request from the students' PC are transmitted to the 
server PC of the lecturer and by acceptance of the request, 
the multicast transmission occurs. 



Figurel. Network relation in a multicast classroom 
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Figure2. Network layout for classroom lecturing 
System flow diagram 



Figure3. Multicast classroom application system flow 
diagram 

Multicasting algorithm 
Server algorithm 

1. Start the SendTimer 

2. When the SendTimer is expired, Capture the Current 
Screen and save as Memory Image. 

3. Change the Image to Byte array and send to 
MulticasterJP (224.100.0.1] 

4. Wait for the next expire of SendTimer. 
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Client algorithm 

1. Start the RecvTimer 

2. When the RecvTimer is expired, receive the byte array 
and save as Memory Image. 

3. Show the image 

4. Wait for the next expire of RecvTimer. 

Multicast process 

Server side (Lecturer's computer) 

The server side main control will be displayed. There will be 
2 options. 



Figure4. Start the classroom lecturing from server 
side 

If "Screen Sharing" is selected, the following menu will 
appear. 



Figure5. Start the screen sharing 

If "Start" is selected, the teacher (server) screen will be 
shown to all connected clients (students). 

If "Stop" is selected, the screen sharing process will 
terminate 

The following text message screen will appear when "Text 
Messaging" is selected. The lecturer can send Instant 



Figure6. Start text messaging 


Client side (student) Client side menu will be shown as 
follows 



Figure7. Start lecturing from client side 


"View screen Sharing" option will let the students join the 
classroom. The server screen (lecturer's screen) will be 
shared to the student's computer. When teacher send 
messages, the clients can see the messages from their 
computers. 


Message 1 from Teacher 
Messages from Teacher 
Message3 from Teacher 


Figure8. Receive messaging from server side 

"Text Messaging" option will let the students see the 
messages sent by their lecturer. 

C. Conclusion 

The aim of this system is using Multicast protocol for class 
room lecturing with lecture demonstration screen sharing 
and classroom discussion. In practice, the use of shared 
computer screen and multicast messaging is an applicable 
system. This system can also assist distance learning on the 
internet infrastructure and benefit students who are in 
remote area. 
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